Release 10.1A: OpenEdge Development:
ADM and SmartObjects

Transactions and record locking

The transaction logic built into the standard SmartObjects (in particular, the SmartDataObject and its supporting files data.i and the super procedure data.p) uses optimistic locking. No database records are locked when they are initially read and transferred into the RowObject temp-table. When an update is committed, the corresponding database records are re-read with an EXCLUSIVE-LOCK. If a lock conflict occurs, the commit is aborted and this information is reported to the user. In the case of an add or copy operation, the record CREATE for the new record is performed inside of this transaction block.

Next, by default, the SmartDataObject verifies that the database records were not modified by another user since they were first read. If you want to skip this check, set the checkCurrentModified property in the SmartDataObject to NO in the instance properties dialog box for the SmartDataObject when assembling an application. Alternately, you can set it to NO in the initialization code for the SmartDataObject.

Finally, only those fields actually modified by the application are ASSIGNed back to the database records. Because the code uses the ChangedFields field in the update temp-table (RowObjUpd) to keep track of which fields were changed, it is necessary to update this field by hand if user-written application code is used; for example, if the RowObjectValidate procedure in a SmartDataObject modified fields beyond those changed in a SmartDataViewer or SmartDataBrowser.

When the update is complete, the database records are re-read to capture any field values that might have been assigned by the CREATE, WRITE, or ASSIGN triggers, and those values are passed back to the client objects for display. A transaction is never held open while data values are examined or entered.